“SQL Server isn’t slow – it’s doing exactly what you told it to do” – a chat with David Klee

Listen on:

Kellyn Gorman is joined by veteran Data Platform Architect, David Klee, to talk all things SQL Server performance tuning. Learn why “it’s slow” is the least useful thing anyone can tell a DBA, why you need a real baseline before diagnosing anything, and why a database is never ‘just’ a database – plus much more.

Thanks to David for his time. You can find him at https://www.davidklee.net/

Why “SQL Server is slow” means nothing: 10 key SQL Server performance tuning tips

Don’t have time to listen or watch? Here are the 10 key takeaways from the episode:

1. “It’s slow” is a starting point – not a diagnosis

When someone says SQL Server is slow, David Klee’s first move is to reject the premise – and you probably should, too. The database is doing exactly what it was designed and coded to do. The real question is what changed – and compared to what baseline. Without a baseline, “slow” is more a feeling than a fact.

2. A database is one piece of a much bigger ecosystem

Database performance problems rarely live in isolation – applications, integrations, backups, infrastructure, and data volume all interact with it. Understanding what a system is actually for – for example, is it a nightly report job, or an e-commerce platform serving millions of users? – has to come before any tuning begins.

3. “Nothing has changed” is almost never true

Data volume changes constantly, even without a deployment. Claims that “nothing changed” should be treated with skeptically. A system can quietly cross a tipping point in data volume very easily, or perhaps there’s a usage pattern change that produces a sudden, visible performance cliff.

4. Know when to stop tuning

Not every slow query is worth fixing. Klee described tuning a report from an overnight run down to just five seconds, but then declining to spend 40 more hours shaving it to two seconds, because the business impact it would have was so insignificant. The real question is always net impact: does it save money, reduce resource consumption, or meaningfully improve the user experience? Or, is it just tuning for tuning’s sake?

5. Quantify before you prioritize

Building a tuning backlog starts with data, not instinct. You need the answer to questions like: which queries are top CPU or memory consumers, which run constantly versus rarely, and which cause blocking or contention? Addressing the top 5% of resource consumers often resolves 70-80% of overall system pain.

6. Index tuning is usually the highest-leverage fix

Compared to rewriting queries or upgrading hardware, index tuning delivered some of the biggest wins Klee describes during the episode. A standout case: a health check showed CPU utilization drop from 70-80% busy to just 20-30% busy after a single round of index tuning, effectively doubling the machine’s usable capacity.

7. There’s no universal rule for “too many indexes”

In the episode, Klee pushes back on rules of thumb like “never more than four indexes on a table.” He’s seen 50 well-used indexes work fine on a heavily reported-on table, but only two indexes be “one too many” elsewhere. It depends entirely on how the table is actually used, and whether every index is earning its maintenance overhead.

8. Metrics only mean something together – not alone

Real diagnosis requires correlating OS-level metrics (CPU, memory, disk latency, network) with SQL Server-level metrics (wait stats, page life expectancy, latches, transactions per second, TempDB activity). Klee leans heavily on dynamic management views (DMVs) and freely available diagnostic scripts to get unfiltered, contextual data.

9. The cloud hides complexity rather than removing it

Moving to a VM (virtual machine), managed instance, or PaaS (platform-as-a-service) database, removes direct visibility into infrastructure problems. That’s not the same as eliminating them – the problems are still there! In the episode, Klee shares a case where a failing storage volume on Amazon RDS caused erratic performance for weeks before Amazon’s own monitoring caught up. DBAs are often the canary in the coal mine, noticing infrastructure problems before the actual infrastructure team does.

10. Once you understand the foundations, everything else is evolutionary

Klee’s closing advice for DBAs navigating AI and constantly-changing platforms: the underlying concepts (storage, memory, execution plans, cause-and-effect relationships between layers) don’t really change – only the branding does. DBAs who understand these foundations can quantify problems, defend their conclusions, and stop being the default target of blame when something elsewhere in the stack goes wrong.

In summary…

David Klee’s approach to performance tuning is less about clever tricks and more about discipline. Establish baselines, quantify impact before acting, and understand how every layer of the stack – from disk, to hypervisor, to query plan – affects the ones above it.

Done well, this discipline doesn’t just make systems faster. In one case Klee described, it even directly increased a manufacturer’s daily vehicle output enough to move their stock price.